Adapt SVGs to book theme

src/ch04-01-what-is-ownership.md

@@ -268,11 +268,7 @@ the memory that holds the contents of the string, a length, and a capacity.
 This group of data is stored on the stack. On the right is the memory on the
 heap that holds the contents.
 
-<img alt="Two tables: the first table contains the representation of s1 on the
-stack, consisting of its length (5), capacity (5), and a pointer to the first
-value in the second table. The second table contains the representation of the
-string data on the heap, byte by byte." src="img/trpl04-01.svg" class="center"
-style="width: 50%;" />
+{{#include img/trpl04-01.svg}}
 
 <span class="caption">Figure 4-1: Representation in memory of a `String`
 holding the value `"hello"` bound to `s1`</span>
@@ -288,9 +284,7 @@ pointer, the length, and the capacity that are on the stack. We do not copy the
 data on the heap that the pointer refers to. In other words, the data
 representation in memory looks like Figure 4-2.
 
-<img alt="Three tables: tables s1 and s2 representing those strings on the
-stack, respectively, and both pointing to the same string data on the heap."
-src="img/trpl04-02.svg" class="center" style="width: 50%;" />
+{{#include img/trpl04-02.svg}}
 
 <span class="caption">Figure 4-2: Representation in memory of the variable `s2`
 that has a copy of the pointer, length, and capacity of `s1`</span>
@@ -300,9 +294,7 @@ look like if Rust instead copied the heap data as well. If Rust did this, the
 operation `s2 = s1` could be very expensive in terms of runtime performance if
 the data on the heap were large.
 
-<img alt="Four tables: two tables representing the stack data for s1 and s2,
-and each points to its own copy of string data on the heap."
-src="img/trpl04-03.svg" class="center" style="width: 50%;" />
+{{#include img/trpl04-03.svg}}
 
 <span class="caption">Figure 4-3: Another possibility for what `s2 = s1` might
 do if Rust copied the heap data as well</span>
@@ -338,11 +330,7 @@ because Rust also invalidates the first variable, instead of being called a
 shallow copy, it’s known as a *move*. In this example, we would say that `s1`
 was *moved* into `s2`. So, what actually happens is shown in Figure 4-4.
 
-<img alt="Three tables: tables s1 and s2 representing those strings on the
-stack, respectively, and both pointing to the same string data on the heap.
-Table s1 is grayed out be-cause s1 is no longer valid; only s2 can be used to
-access the heap data." src="img/trpl04-04.svg" class="center" style="width:
-50%;" />
+{{#include img/trpl04-04.svg}}
 
 <span class="caption">Figure 4-4: Representation in memory after `s1` has been
 invalidated</span>

src/ch04-02-references-and-borrowing.md

@@ -24,9 +24,7 @@ function return value is gone. Second, note that we pass `&s1` into
 `String`. These ampersands represent *references*, and they allow you to refer
 to some value without taking ownership of it. Figure 4-5 depicts this concept.
 
-<img alt="Three tables: the table for s contains only a pointer to the table
-for s1. The table for s1 contains the stack data for s1 and points to the
-string data on the heap." src="img/trpl04-05.svg" class="center" />
+{{#include img/trpl04-05.svg}}
 
 <span class="caption">Figure 4-5: A diagram of `&String s` pointing at `String
 s1`</span>

src/ch04-03-slices.md

@@ -123,11 +123,7 @@ byte at index 6 of `s` with a length value of `5`.
 
 Figure 4-6 shows this in a diagram.
 
-<img alt="Three tables: a table representing the stack data of s, which points
-to the byte at index 0 in a table of the string data &quot;hello world&quot; on
-the heap. The third table rep-resents the stack data of the slice world, which
-has a length value of 5 and points to byte 6 of the heap data table."
-src="img/trpl04-06.svg" class="center" style="width: 50%;" />
+{{#include img/trpl04-06.svg}}
 
 <span class="caption">Figure 4-6: String slice referring to part of a
 `String`</span>

src/ch15-01-box.md

@@ -178,7 +178,7 @@ type needs, the compiler looks at the variants, starting with the `Cons`
 variant. The `Cons` variant holds a value of type `i32` and a value of type
 `List`, and this process continues infinitely, as shown in Figure 15-1.
 
-<img alt="An infinite Cons list" src="img/trpl15-01.svg" class="center" style="width: 50%;" />
+{{#include img/trpl15-01.svg}}
 
 <span class="caption">Figure 15-1: An infinite `List` consisting of infinite
 `Cons` variants</span>
@@ -232,7 +232,7 @@ broken the infinite, recursive chain, so the compiler can figure out the size
 it needs to store a `List` value. Figure 15-2 shows what the `Cons` variant
 looks like now.
 
-<img alt="A finite Cons list" src="img/trpl15-02.svg" class="center" />
+{{#include img/trpl15-02.svg}}
 
 <span class="caption">Figure 15-2: A `List` that is not infinitely sized
 because `Cons` holds a `Box`</span>

src/ch15-04-rc.md

@@ -35,7 +35,7 @@ Let’s return to our cons list example in Listing 15-5. Recall that we defined
 it using `Box<T>`. This time, we’ll create two lists that both share ownership
 of a third list. Conceptually, this looks similar to Figure 15-3:
 
-<img alt="Two lists that share ownership of a third list" src="img/trpl15-03.svg" class="center" />
+{{#include img/trpl15-03.svg}}
 
 <span class="caption">Figure 15-3: Two lists, `b` and `c`, sharing ownership of
 a third list, `a`</span>

src/ch15-06-reference-cycles.md

@@ -75,7 +75,7 @@ well. This instance’s memory can’t be dropped either, because the other
 remain uncollected forever. To visualize this reference cycle, we’ve created a
 diagram in Figure 15-4.
 
-<img alt="Reference cycle of lists" src="img/trpl15-04.svg" class="center" />
+{{#include img/trpl15-04.svg}}
 
 <span class="caption">Figure 15-4: A reference cycle of lists `a` and `b`
 pointing to each other</span>